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In preparation for the telephone interview on February 26 at 2pm EST, Applicai^are 
submitting this proposed interview agenda. In addition, to facilitate the discussion Applicants 
are submitting pages 4 and 5 from the specification for discussion. 

In the outstanding Office Action, the Examiner rejected claims 1-30 under 35 U.S.C." ' 
§103(a) as obvious in view of U.S. Patent No. 5,737,597 to Blackman et al. (hereinafter 
"Blackman"), a publication from W3C on WIDL (hereinafter "WIDL"), U.S. Patent No. 
6,038,393 to Lyengar et al. (hereinafter "Lyengar"), a publication on "XMI Opens Application 
Interchange" by Brodsky (hereinafter "Brodsky"), and U.S. Patent No. 6,182,029 to Friedman et 
al. (hereinafter "Friedman"). 



REMARKS 

Applicants would like to discuss where objective teachings that suggest the claimed 
subject matter of claims 1,11, and 21 are specifically taught in the prior art. See In re Fine, 837 
F.2d 1071, 1074, 5 USPQ2d 1596, 1598 (Fed. Cir. 1988). 

Specifically, Applicants would like to discuss where the prior art teaches "generating an 
XML document template from an IMS message definition; and merging an IMS message with 
the generated template to produce a corresponding XML document." (claim 1, emphasis added). 
In particular, Applicants find only a cursory reference to IMS in Blackman and no references in 
any of the prior art to an "IMS message definition" or "an IMS message" which are specifically 
recited in claim 1. Applicants submit that such clear and specific language limits the scope of the 
present invention to steps involving EMS message definitions. Applicants submit that giving this 
term its "plain meaning" clearly defines the invention and places the invention outside the scope 
of the prior art. See In re Zletz, 893 F.2d 319, 321, 13 USPQ2d 1320, 1322 (Fed. Cir. 1989), 
MPEP §2111.01. 

Applicants would like to discuss how the prior art which does not discuss messaging in 
IMS can rise to the level of a combination of prior art references that teaches or suggests all the 
claim limitations as required for a rejection under 35 USC §103(a). See MPEP § 2142. In 
particular, the prior art fails to teach anything regarding an "IMS message definition" or "an IMS 
message." 

Blackman discusses building object oriented software to interconnect object oriented 
applications with non-object oriented datastores such as IMS. Blackman teaches software for 
accessing IMS data (a data level operation), not interacting (exchanging messages, an application 
level operation) with an IMS application. Applicants would like to discuss how an IMS message 
definition deals with messaging between an IMS system and an external application, not 
accessing data. 

Applicants would also like to discuss failure of the prior art to generate a template in any 
format based on I/O message formats, IMS message definitions. Applicants would like to 
discuss the following definition of template. "In spreadsheet and database applications, a 
template is a blank form that shows which fields exist, their locations, and their length. In 
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spreadsheet applications, for example, a template is a spreadsheet in which all the cells have 
been defined but no data has yet been entered." (Emphasis Added) 
WWW.WEBOPEDIA.COM . Applicants would like to discuss where such a template is 
disclosed in the prior art. 

Finally, Applicants would like to discuss where in the prior art references one of ordinary 
skill in the art would be motivated to make the combination suggested by the Examiner. 
Applicants would like to discuss how one with a computer science or electrical engineering 
degree, one of ordinary skill in the art, would interpret the cited prior art. Furthermore, 
Applicants would like to understand why one of ordinary skill in the art would make the 
combination suggested by the Examiner when the combination lacks such important elements, 
the IMS messages and IMS message definitions. 

If any issues remain that can be resolved by a telephone conversation, the Examiner is 
respectfully requested to contact the undersigned. 

Respectfully submitted, 




David J. McKenzie 
Reg. No. 46,919 
Attorney for Applicant 



Date: February 18,2004 
8 E. Broadway, Suite 600 
Salt Lake City, UT 84111 
Telephone (801)994-4646 
Fax (801)531-1929 
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For example, as illustrated in Figure 3, the IMSCTL 26 controls one or more 
connected terminals 28, sending and receiving messages to and from the terminals 
28. Moreover, the IMSCTL 26 logs all transactions in order to provide the capability 
of undoing non-committed transactions in the event of a system failure. 

In addition, every time the IMSCTL 26 receives an input message 30 from a 
terminal 28, it schedules an application 18 to process the message 30. The IMSCTL 
26 identifies the desired application 18 and puts the message 30 in the application's 
message queue 32. The application 18 processes the message 30 and responds to the 
originating terminal 28 by placing an output message 30 in the terminal's message 
queue 34. 

As illustrated in Figure 4, an input message 30 typically includes the 
following fields: 

LL Length of the message segment. 

ZZ Reserved for IMS. 

TRANCODE Transaction code that identifies the application 18. 
Text Message text sent from the terminal 28 to the 

application 18. 

The structure of an output message 30 is similar, except that the TRANCODE field 
is missing. 

In general, messages 30 belong to one particular IMS application 18. When 
the application 18 is implemented, the format of the message 30, including the types 
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and lengths of its fields, must be defined. The format of a message 30 is referred to 
herein as a message definition 38. Message definitions 38 may be implemented 
using various programming languages, such as COBOL, assembler, PL/I and 
Pascal. For example, the message definition 38 illustrated in Figure 4 is 
implemented in COBOL. 

Unfortunately, IMS messages 30 are in a proprietary format, whereas the 
Internet is based on open standards, such as the HyperText Markup Language 
(HTML), a variant of the extensible Markup Language (XML). As a result, 
interfacing IMS with remote systems via the Internet can be difficult. Accordingly, 
what is needed is a system and method for representing IMS messages 30 in an 
open, interchangeable format, such as XML. 
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